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Abstract 

In this paper we introduce a new complexity 
metric to predict -in real-time- sector complexity for 
trajectory-based operations (TBO). TBO will be 
implemented in the Next Generation Air 
Transportation System (NextGen). Trajectory-Based 
Complexity (TBX) is a modified aircraft count that 
can easily be computed and communicated in a TBO 
environment based upon predictions of aircraft and 
weather trajectories. TBX is scaled to aircraft count 
and represents an alternate and additional means to 
manage air traffic demand and capacity with more 
consideration of dynamic factors such as weather, 
aircraft equipage or predicted separation violations, 
as well as static factors such as sector size. We have 
developed and evaluated TBX in the Airspace 
Operations Laboratory (AOL) at the NASA Ames 
Research Center during human-in-the-loop studies of 
trajectory-based concepts since 2009. In this paper 
we will describe the TBX computation in detail and 
present the underlying algorithm. Next, we will 
describe the specific TBX used in an experiment at 
NASA’s AOL. We will evaluate the performance of 
this metric using data collected during a controller-in- 
the-loop study on trajectory-based operations at 
different equipage levels. In this study controllers 
were prompted at regular intervals to rate their 
current workload on a numeric scale. When 
comparing this real-time workload rating to the TBX 
values predicted for these time periods we 
demonstrate that TBX is a better predictor of 
workload than aircraft count. Furthermore we 
demonstrate that TBX is well suited to be used for 
complexity management in TBO and can easily be 
adjusted to future operational concepts. 

Introduction 

The Next Generation Air Transportation System 
(NextGen) is being developed to transform the 
current system to the one envisioned for the future by 
increasing capacity/throughput, improving flight and 


system efficiency, all while maintaining overall 
system safety [1], A number of human-in-the-loop 
studies have been conducted in the Airspace 
Operations Laboratory (AOL) at the NASA Ames 
Research Center to evaluate mid-term NextGen 
concepts [2, 3], NextGen concepts such as Multi- 
Sector Planning and Dynamic Airspace 
Configuration required the use of a sector complexity 
estimate instead of using a simple aircraft count. 
Although predicted aircraft count is used in today’s 
air traffic management to manage a maximum traffic 
threshold, it is well known that aircraft count alone is 
not the best predictor of traffic complexity [4]. In 
addition, mid-term NextGen environments are 
expected to have diverse avionics and ground 
equipage, which further complicate the relationship 
between simple aircraft count and controller 
workload, making the need for new complexity 
metrics vital. 

Although various complexity metrics have been 
proposed and studied over the past decades [e.g., 4- 
11], they were unsuitable for use during our real-time 
human in the loop simulations. One of the main 
reasons was that many complexity computations 
were computed off-line and matched to previously 
collected data rather than in real-time based upon 
current and predicted data. The resulting metrics that 
provided good statistical fit to the historical data were 
often ill-suited to characterize the uncertainties 
associated with traffic predictions. Another 
shortcoming of many complexity metrics was that 
they were not easily understood by human operators 
in ways that allowed them to interpret the data and 
translate them into actions that support air traffic 
management. Finally, the existing metrics were often 
designed for current-day operations rather than 
trajectory-based operations (TBO) planned for 
NextGen. 

A new Trajectory-Based Complexity (TBX) was 
developed to support NextGen concept evaluations in 
NASA’s AOL. TBX has many similarities to past 


approaches in the complexity research but its 
implementation is different in many ways. In the 
following sections, past approaches to calculating 
traffic complexity are described, followed by the 
details of TBX calculations. 

Background 

In today’s air traffic operations, a sector’s 
predicted aircraft count is used to determine the 
maximum traffic threshold that a controller can 
handle in that sector. The maximum threshold value 
is called Monitor Alert Parameter (MAP) and its 
value (i.e. maximum aircraft count in a sector) is set 
based on average sector flight time. However, the 
MAP values and the predicted aircraft count alone 
have been insufficient to correctly measure controller 
task loads without considering other factors that vary 
the traffic complexity [5]. 

One of the main efforts in traffic complexity 
research is targeted towards developing Dynamic 
Density (DD) metrics. It is a method to identify 
numerous factors that contribute to traffic complexity 
and that correlate with controller workload. A large 
set of metrics have been proposed as DD metrics [4]. 
Although DD metrics correlated better with 
controllers’ workload ratings than the aircraft count 
alone, the total number of DD metrics initially 
exceeded fifty and the number still remained above 
ten after further down-selection. Simplified Dynamic 
Density (SDD) was another way to down-select a 
subset of DD metrics to those that were readily 
available in the current Enhanced Traffic 

Management System (ETMS) [6], The identified 
SDD metrics were sector occupancy counts, 
proximities in a sector, altitude transitions in a sector, 
transfers across sector boundaries, number of aircraft 
per sector volume, variance of aircraft headings in 
sector, and variance of cruising aircraft speeds in 
sector. 

Despite the better prediction of traffic 
complexity and controller workload, regression 
methods that fit the controller workload to different 
DD metrics are only valid for the fitted sectors. The 
weightings of the factors change significantly for 
different sectors and the methodology offers no easy 
solution to modify the factor weightings to adapt the 
past calculations to new sectors. Furthermore, many 
of the DD factors are not suited for traffic flow 
management (TFM) [7]. If DD metrics exceed the 


maximum threshold, it is not obvious which actions 
should be taken in order to solve the problem [7]. 
Some of the DD metrics also exhibit large 
uncertainty when they are projected to the TFM time 
horizon (e.g. one to two hours), which results in 
significant fluctuations of the combined complexity 
values [8]. 

A different approach to measuring traffic 
complexity is to select a few complexity factors that 
the air traffic controllers can readily identify and 
solve within the TFM time horizon. For example, 
Masalonis and his colleagues [7] asked five Traffic 
Management Coordinators (TMCs) various workload 
factors that they considered in their decision making. 
The factors that they identified included predicted 
peak aircraft count, percentage of sector capacity lost 
due to severe weather, weather at the destination 
airport, traffic at same altitude on merging/crossing 
flows, impact of weather on other surrounding 
sectors, total aircraft count, arrival and departure 
push near a sector, traffic at same altitude with lateral 
proximity, and amount of time the sector stays above 
MAP. 

In a similar approach, Hilbum and Flynn 
identified complexity factors for the Complexity and 
Capacity (COCA) project [9]. They identified the 
following factors based on the discussions with 
controllers: a mix of climbing and descending 
aircraft, turbulence/weather, military/other restricted 
areas, traffic flows converging at the same point, 
traffic bunching, radio congestion, high number of 
aircraft, multiple crossing points, mix of climbing 
and descending flights in cruise, crossing points close 
to boundaries, merging of arrival flows, and mix of 
high and low performance aircraft. They also 
identified some of these factors as “precursor” 
factors, whose presence elevates the complexity of 
other factors. Some of the pre-cursor factors 
identified by the controllers were frequency 
congestion, mix of climb/descent traffic, high number 
of aircraft, emergencies, military/other restricted 
areas, turbulence/weather, and non-nominal 
equipment status. 

Histon and Hansman [10] proposed three 
categories of ATC complexity: situation, perceived, 
and cognitive complexity. They define situation 
complexity as an intrinsic property of the traffic 
situation; perceived complexity as subjective 
complexity experienced by the controllers; and 


cognitive complexity as the complexity of the mental 
models and strategies that controllers use to perform 
air traffic management tasks. They then focus their 
research on cognitive complexity which drives 
controller workload [10]. 

In a series of follow-up studies, Hansman and 
his colleagues proposed an integrated metric called 
Modified Aircraft Count (MAC), which consists of 
combinations of factors that account for different 
components of cognitive complexity [11], The MAC 
metric is calibrated to represent the effective number 
of aircraft in a sector as a replacement for today’s 
MAP which is based on the predicted aircraft count. 
The MAC is a combination of each aircraft’s 
contribution to cognitive complexity (called Aircraft 
Multiplier, or AM), which is then multiplied by 
sector level complexity (called Sector Multiplier, or 
SM), such as its shape, Letters of Agreements 
(LOAs), etc. Examples of AM complexity factors are 
aircraft proximity, sector boundary encounters, 
weather impacting area encounters, 
climbing/descending aircraft, location relative to 
critical points, and communication capability (e.g. 
Data Comm or voice). Examples of SM factors are 
airspace volume, number and position of 
ingress/egress points, spatial distribution of airways, 
and traffic restriction (e.g. metering). 

TBX overview 

In our complexity calculations, we tried to avoid 
some of the pitfalls of prior approaches while 
keeping some of the features that would work well 
for predicted complexity calculations that human 
operators could use for TFM purposes. The 
characteristics of these features were: 

• Metrics that were comprehensible to human 
operators 

• Metrics whose weightings would be easy to 
modify for new equipage and operational 
environments 

• Metrics that were stable over the prediction 
time horizon 

• Use of TBO to create more stable trajectory 
predictions over a 1 - 2 hour time horizon 

• Combination of different complexity factors 
into a single modified aircraft count value 


that human operators could use in 
conjunction with a MAP value 

In order to be able to support real-time TFM, 
TBX is designed for real-time computations of 
complexity estimates based upon predictions of four- 
dimensional trajectories for weather and aircraft. 
TBX accounts for the differences in controller task 
load associated with maintaining TBO for different 
equipage levels, and the increased complexity 
associated with climbing and descending aircraft. The 
factors that provide inputs to TBX calculations were 
obtained from discussions with subject matter experts 
and therefore were easily accessible and 
understandable by the operators. As a real-time 
estimate, TBX can provide immediate what-if 
feedback on the complexity impact of potential 
trajectory and/or airspace changes. This allows traffic 
managers and area supervisors to preview the impact 
of potential solutions to capacity/demand imbalances 
before deciding on and implementing a specific 
strategy. 

Calculating the TBX value is based upon 
establishing capacity definitions for nominal 
conditions, comparing the currently predicted 
conditions to those nominal conditions, and then 
adjusting the aircraft count accordingly. Thus, TBX 
values mimic aircraft count and the same mechanism 
of setting capacity thresholds using a MAP that 
reflects the maximum aircraft count can be used with 
TBX. The TBX value will be equal to the predicted 
aircraft count for a “nominal” sector size, a nominal 
number of transitioning aircraft and a nominal 
equipage mix, but any predicted difference to 
nominal operations, such as convective weather cells, 
different aircraft equipage mixes, unusually high 
levels of transitioning aircraft or traffic conflicts, 
causes a modification to the aircraft count, which will 
be reflected in the respective TBX value. Using 
Figure lwe will illustrate the use of TBX. 

Figure 1 shows excerpts from a traffic situation 
display (top), a load table (bottom left) and a load 
graph (bottom right) to illustrate an example from a 
simulation run in the Kansas City Center (ZKC) 
airspace. The traffic situation display indicates three 
sectors, marked 94, 98 and 90, with a weather system 
present in sector 94. The load table shows the 
predicted peak aircraft count and TBX value of these 
three sectors for the next three 15 minute time 
periods. The peak aircraft count is the upper number 


in each cell. TBX, the predicted complexity, is the 
lower number in each cell. The load graph shows the 
predicted TBX value for sector 94 for the next 75 
minutes. In this simulation, which assumed a mid- 
term environment with many data link equipped 
aircraft and several decision support tools for the 
controllers, the MAP for each sector was set to 24 
instead of today’s 18. 


many transitioning aircraft that makes it generally 
more complex than ZKC 94. Because more aircraft 
are diverted around the weather, ZKC90, which 
currently does not look very complex, will be subject 
to dense traffic flows entering form the north east that 
create additional conflicts and will make the high 
number of aircraft predicted to enter even less 
manageable. 


Based upon aircraft count alone, ZKC 98 and 
ZKC 94 would not reach nor exceed the MAP value. 
TBX however predicts that in 15 to 30 minutes both 
sectors will show a similar workload for the 
controllers as 25 or 28 aircraft would under normal 
conditions. The reason is that the weather system 
impacts aircraft in both sectors and requires reroutes. 
Furthermore, sector ZKC 98 is a small sector with 


In this situation, a traffic management 
coordinator or area supervisor looking at aircraft 
count alone would be mostly concerned with sector 
ZKC90 and perhaps reroute aircraft into ZKC 98. 
However, using TBX it becomes clear that all three 
sectors will be saturated (i.e., red numbers in load 
table); and to compensate for this, ZKC 94 and 
ZKC 98 should be managed with R-Side and D-Side 
controller teams. Two to three 
more aircraft might need to be 
moved, so they will not enter into 
ZKC 90, ZKC 98 and ZKC 94. 
This will bring the TBX values for 
each sector down to nominal 
levels. 

As the example indicates, 
TBX is based upon comparing 
predicted conditions to nominal 
conditions and making 
adjustments to the actual aircraft 
count that reflect the differences. 
The result can be interpreted as a 
“feels like” value. In the example 
in Figure 1, there are 18 aircraft 
predicted to be in sector ZKC 94, 
but it may feel to the controller 
like 22 aircraft, because the 
workload to manage 18 aircraft in 
a weather impacted sector may be 
similar to the workload associated 
with managing 22 aircraft under 
nominal conditions. The TBX 
computation takes weather 
penetration into account and as the 
TBX value in ZKC 94 reaches 28, 
it exceeds the monitor alert 
parameter of 24 set for this sector. 
Therefore, the TBX value of 28 
indicates that the sector will be 



Figure 1: Traffic situation, load table and load graph 


overloaded. The load graph at the 
bottom right of Figure 1 indicates 













exactly how long this situation will prevail, thereby 
giving the operator more information. This 
information may help them to decide whether the 
sector team can handle the situation or whether 
aircraft will need to be rerouted. 

In the preceding section we tried to demonstrate 
the value in using TBX in addition to aircraft count. 
The following sections will illustrate the TBX 
calculation approach step by step. 

TBX calculation 

The TBX calculation consists of two a-priori 
detenninations prior to being computed in real-time: 

1. Define nominal conditions, in which 
aircraft count is a good predictor of 
controller workload 

2. Define adjustments to the nominal 
conditions that capture the differences in 
complexity between the current conditions 
and the nominal conditions. 

3. Compute the TBX value 

Nominal Conditions 

The nominal conditions are those conditions 
under which the aircraft count is an excellent 
predictor of sector complexity. These are the nominal 
conditions within a sector and can be defined through 
knowledge elicitation sessions on a sector by sector 
basis or based upon more generic attributes. Up until 
now we used TBX for the high altitude airspace and 
we defined nominal conditions for that environment 
with only small variations for each simulation. For 
our simulations, we have defined a nominal sector to 
be a square 100 nmi by 100 nmi sector with a 
nominal number of aircraft in the sector to be 80 % of 
the MAP value. It is also defined to have 10% of all 
aircraft with predicted loss of separation within the 
next 8 minutes and 20% of the aircraft to be climbing 
or descending. In the nominal conditions no aircraft 
are expected to penetrate weather. Nominal equipage 
mixes and MAP values depend on the simulated 
NextGen environment. For current day operations our 
nominal equipage mix has 0% Data Comm equipped 
aircraft and a MAP value of 18. For a mid-term 
environment, we may assume 40% equipped aircraft 
and a MAP value of 23 and for a far-term more 
advanced environment we may assume 100% 


equipage and a MAP value of 45. TBX allows 
subject matter experts to define the nominal 
conditions easily that will help relate aircraft count, 
TBX and MAP. 

Adjustments 

Adjustments are ratios that describe the 
relationship between a nominal value and the current 
value. In line with prior research and SME interviews 
there are two types of adjustments that should be 
made to the aircraft count to account for the different 
properties of the complexity impacts: 

1. Primary (or dominant) complexity 
adjustments - those factors that can cause a 
similar effect to the complexity as the aircraft 
count, can offset the aircraft count, or have a 
detrimental impact. These factors are 
expected to have a multiplicative effect on 
the aircraft count and their impact is expected 
to scale with the current aircraft count. 
Primary adjustments are made for dominant 
items such as weather or sector size. 

2. Secondary complexity adjustments - those 
factors have a secondary impact on 
complexity. They can be specific to a given 
operational environment and have a smaller 
impact on complexity than the primary 
factors. Their impact is less dependent on the 
overall aircraft count. Secondary adjustments 
are made for items such as number of 
conflicts, or number of transitioning aircraft. 

Computation 

In its general form we compute the TBX value 
as shown in equation (1). The TBX value of a sector 
s at time t equals the sum of its predicted aircraft 
count (ac) multiplied by the product of the primary 
adjustments (px) and the nominal aircraft count 
multiplied by the weighted sum of the secondary 
adjustments (sx) -1. 

TBX and its adjustments are defined such that 
their value under nominal conditions is 1. This 
satisfies equation (2) below, which simply states that 
the TBX value of a sector s at time t under nominal 
conditions equals its predicted aircraft count at time t. 
In addition, all adjustments px,(s) and sx js) are 
limited to a range of 0 to 2 to prevent one factor from 
dominating the overall TBX value. 


( 1 ) 


n 

tbx(s, t) = ac(s, t) * n px t (s, t) + ac nom (s ) * 

i=o 



tbx nom (s, t) = ac(s, t) 

where 

5 is the sector of interest 

t is the time for which the complexity is computed 

tbx (s, t) is the predicted trajectory-based complexity of sector s at time t 

ac (s, t) is the predicted aircraft count of sector s at time t 

pxj(s,t) is the adjustment for primary complexity item i in sector s at time 1 

ac nom (s) is the nominal aircraft count in sector s 

Wj is the weight of secondary complexity item j 

sxj(s,t) is the adjustment for secondary complexity item j in sector s at time t 


( 2 ) 


By setting up the calculations in this fashion, 
we can define the MAP values based on nominal 
conditions for a given sector and then compare 
aircraft count and TBX value relative to the MAP to 
assess the peak that exceeds the MAP. This method 
of presenting TBX values in the same format as 
aircraft count makes the interpretation of TBX easy 
for controllers. 

Complexity Factors 

After having presented the mathematical 
formulation of TBX, and before diving into specific 
examples and results, in this section we review the 
main complexity factors that we used. While many 
complexity factors exist, not all of them are useful, 
nor can or should they be used for all operational 
environments. 

Complexity factors for TBX need to be 
meaningful to the operators and predictable for 
computers. In knowledge elicitation sessions with 
subject matter experts the following short list of 
complexity factors for a mixed equipage en route 
airspace was composed: 

• Aircraft count 

• Weather 

• Sector volume 

• Number of transitioning aircraft 


• Conflicts 

• Aircraft equipage 

These factors have evolved over the years as the 
different simulation studies focused on some of the 
factors more than others. The actual calculations have 
been modified as well in response to how well they 
functioned in the studies. As we find better 
mathematical representations of the factors based on 
their efficacy in future studies, we expect to further 
modify and refine the complexity calculations. In the 
following sections, the calculations of the current 
complexity factors will be described more in detail. 

Aircraft Count 

TBX is based upon the assumption that aircraft 
count is the best predictor of workload under nominal 
conditions. Therefore, the aircraft count is a dominant 
factor and equation (1) makes this relationship 
explicit. Equation (2) on the previous page requires 
that the adjustment for the aircraft count needs to be 
linear. Therefore the aircraft count adjustment is 
simply 

px ac {s, f) = ac (s, t ) 

Where 

px ac is a primary complexity adjustment for 
the aircraft count 


s is the sector of interest 

t is the time for the prediction 

ac (s,t) is the predicted aircraft count at time t 

This relationship is already explicitly included in 
equation (1) and is stated here for completeness. 

Sector Volume 

The sector volume can be an important 
contributor to complexity since larger sectors provide 
more airspace than smaller sectors for maneuvering, 
more time between accepting and initiating handoffs 
and their associated transfers of communication. We 
currently use the following adjustment for sector 
volume: 

p*„fet) = g“) 15 (3) 

where 

px sv is a primary complexity adjustment for 
the sector volume 

,vv is the sector volume of the current sector 
(between its lateral and vertical boundaries) 

sv nom is the nominal sector volume and 

Our current nominal sector is 

sv nom = lOOnmi * lOOnmi * 10,000 ft 

The power of 0.15 has been tuned empirically 
using prior studies by assessing the impact of sector 
size on the overall complexity value and comparing 
the complexity to the corresponding controller 
workload. As with all our adjustments this sector 
volume equation is a simple approximation that 
works reasonably well for sectors of comparable 
properties. Other options are to use different 
functions, to adapt the sector adjustment per sector or 
to scale the MAP value to reflect a specific sector 
more appropriately. 

Weather 

Weather impacts complexity in many ways. It 
limits the available airspace, causes the need for 
rerouting flights and often results in substantial 
increases in communication between pilots and 
controllers. Weather also becomes less predictable 
the further out into the future the prediction is made. 
For our TBX calculation we decided to use the 
number of aircraft that are predicted to penetrate the 


weather within a given sector. Therefore the 
predicted weather trajectory is compared against the 
predicted aircraft trajectory to detennine whether 
these two intersect within a sector. We compute the 
complexity adjustment for weather as follows: 

px wx (s,t) = 1 + 2*^^ (4) 

where 

px wx is a primary complexity adjustment for 
the weather penetrations 

ac wx is the number of aircraft predicted to 
penetrate the weather 

MAP is the Monitor Alert Parameter 

Weather is used as a primary adjustment and 
multiplies the aircraft count. Therefore the equation 
above means that if half of a sectors MAP value will 
penetrate the weather, the complexity is doubled in 
comparison. 

Number of Transitioning Aircraft 

The number of climbing and descending aircraft 
impacts the complexity in multiple ways. Controllers 
have to issue additional instructions; a larger amount 
of airspace needs to be clear of traffic while the 
aircraft are transitioning and the future locations of 
aircraft are more difficult to predict by humans and 
the trajectory automation because of large differences 
in aircraft performance. We integrate the number of 
transitioning aircraft as a secondary adjustment that 
scales independent of the actual aircraft count as 
follows. 

sx trs (s, t) = 1 + - trs nom (5) 

where 

sx trs is a secondary complexity adjustment 
for transitioning aircraft 

ac trs is the predicted number of aircraft to be 
transitioning 

trSnom is the nominal ratio of aircraft to be 
transitioning 

We used trs nom = 0.2 for our high altitude 
environment, which means that in the 
nominal case 20% of the sectors MAP value 
(usually 4-5 aircraft) are transitioning 


Conflicts 

Conflicts between aircraft add to complexity, 
because controllers have to assess the situation and 
maneuver at least one of the conflicting aircraft. This 
often also involves coordinating with adjacent 
sectors, further increasing the workload. Conflicts 
can be predicted by trajectory automation, but 
because of uncertainties, only reliably for up to 20 or 
30 minutes. Therefore conflicts contribute to 
complexity calculations up to the conflict probes look 
ahead time (usually no more than 30 minutes) but 
they are excluded in the calculations beyond that. 

We consider two types of conflict related data 
separately: The number of loss of separation (LOS) 
events that are predicted to occur inside the sector of 
interest and the number of aircraft that have a 
predicted conflict somewhere downstream (whether 
inside or outside of the sector of interest). 

Number of Predicted LOS events 

Conflicts that are predicted to occur within the 
sector are included as follows: 

sx PrL0S (s, t) = 1 + 2* ( PrL ^p S,t) - PrLos nom ) (6) 
where 

sx PrLos i s a secondary adjustment for the 
predicted number of LOS that occur in sector 
s at time t 

PrLos (s, t) is the number of predicted LOS 
events to occur in sector s at time t, if no 
action is taken 

PrLos nom is the nominal value for predicted 
LOS to occur in a sector at time t 

We used PrLos nom = 0.05 for our high altitude 
environment, which means that in the nominal case 
the number of conflicts is about as much as 5% of the 
sectors MAP value. For near-term MAP values of 
~20, we expect one conflict to be predicted in the 
sector at any time 

Number of Aircraft with Predicted Conflicts 

The number of aircraft with predicted conflicts 
is different than the number of predicted LOS events 
as these LOS events can occur in a different sector. It 


is assumed that in a trajectory-based environment 
these would be flagged to the controller. We compute 
the complexity adjustment for this factor as follows: 

SX conf (.S, t) = l + aCC °M Al p S ~ con fnom (7) 
where 

sx CO nf ( s > 1) is a secondary complexity 
adjustment for the number of aircraft with 
predicted conflicts in sector s at time t 

ac conf (+ t) is the predicted number of 
aircraft in sector s at time t that are predicted 
to have a conflict at or after time t 

confnom is the nominal ratio of aircraft with 
predicted conflicts per MAP 

We used conf nom = 0.1 for our high altitude 
environment, similar to the complexity adjustments 
for predicted LOS 

Aircraft Equipage 

Aircraft equipage is meaningful if there are 
equipage differences that lead to much different 
workload levels associated with the equipage types. 
In our studies, which were situated in a mid-term 
environment, we typically distinguished between 
aircraft that can be controlled via Data Comm, and 
those that have to be controlled via voice. Since we 
simulate automated transfer of communication for 
Data Comm equipped aircraft and trajectory uplinks 
they require significantly less work than unequipped 
aircraft. We adjust the complexity for equipage as 
follows: 

r -1 i ac uneq(. s >t) /o\ 

sx uneq(. S ’ t) — 1 3 ac~(sT) une Qnom ($) 

where 

sXuneq ( s > 0 is a secondary complexity 
adjustment for unequipped aircraft in sector s 
at time t 

ac uneq ( s > t) is the predicted number of 
unequipped aircraft in sector s at time t 

ac(s, t) is the predicted number of aircraft in 
sector s at time t 

uneq nom is the nominal ratio of unequipped 
aircraft 


We use uneq nom = 1 (all aircraft unequipped) 
for our near-term environment, uneq nom = 0.5 (50% 
equipped) for our mid-term mixed equipage 
environment, and uneq nom = 0 for our far-term 
full equipage environment. This value needs to be 
selected according to the target environment 

The factors above represent the general factors 
that we use for computing the TBX. This exact set 
was used for mixed equipage simulations that 
investigated flow-based trajectory management and 
multi-sector planning [3, 13]. During these 

simulations, TMCs and area supervisors were highly 
successful in providing service for equipage and 
managing the workload in weather impacted sectors. 
Next we will discuss an example of a specific TBX 
formulation and results from our most recent study 
on Corridors-ln-The-Sky. 

Example: Corridors-ln-The-Sky 

Study Background 

From July 11-22, 2011, a human-in-the-loop 
(H1TL) simulation of the Corridors-ln-The-Sky 
concept was conducted in the AOL This FIITL study 


focused on investigating the feasibility and the 
potential benefits of this concept with air traffic 
controllers in a realistic environment. 

As shown in Figure 2, the airspace in the study 
consisted of super high en route airspace sectors 
(FL330 and above) in the Cleveland Center airspace 
(ZOB). The corridors were designed as one-way 
routes westbound from or eastbound to the New York 
Metro area at two different altitudes. Each corridor 
had two parallel lanes to accommodate different 
speeds of aircraft. 

The corridors were managed by the sector team 
within their respective sectors and were not treated as 
separate airspace. There was a mix of aircraft with 
and without Data Comm. Equipped aircraft had Data 
Comm technologies for uplinks of route, altitude, 
speed, and transfer of communication. Unequipped 
aircraft had no Data Comm and required voice 
instructions by the controllers. All aircraft were 
equipped with flight management systems with area 
navigation (RNAV) capability. 

Feasibility and benefits were tested for four 
different corridor structures: (1) no specific corridors 
(No Corridors), (2) only equipped aircraft within 
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Figure 2: Corridors study test airspace 




corridors (Equipped in Corridors), (3) only 
unequipped aircraft within corridors (Unequipped in 
Corridors), and (4) a mix of both equipped and 
unequipped aircraft within corridors (Mixed in 
Corridors). Surrounding non-corridor traffic 
consisted of 50/50 mix of Data Comm and non-Data 
Comm equipped aircraft in all conditions. 

TBX usage during study 

Prior to the study, a MAP value of 22 was 
established as the maximum traffic that controllers 
could handle under nominal condition. Therefore, 
TBX had to be defined to accommodate the expected 
workload differences in the various conditions and 
the different states and Data Comm equipage types of 
the aircraft compared to the nominal condition. The 
next two paragraphs explain the operational 
environment and the differences that had to be 
captured in the TBX computations. 

In the study, the traffic managers and 
supervisors were told to use TBX to reroute aircraft. 
Traffic Managers were told to keep the TBX value at 
or below 25. Supervisors managed the remaining 
complexities towards a TBX value of 22, which was 
understood to be an approximately match to the 
maximum traffic that controllers could handle. 


Voice communications were available at all 
times between controllers and pilots. Conflict 
detection automation was active and resolution 
support was available. For Data Comm equipped 
aircraft, clearances were sent either via data 
communications and loaded into the FMS, or via 
voice in which the pilot manually performed the 
required actions. Flandoffs and transfers of 
communication for Data Comm equipped aircraft 
were automated and did not require controller 
involvement. For unequipped aircraft, clearances 
were only sent via voice and were typically followed 
by controller actions to update the system 
accordingly. Flandoff initiations were automated, but 
acceptance and transfer of communications were 
performed manually by the controller. 

Non-corridor traffic within the test sectors was 
displayed with full data blocks and was collapsible 
only after being handed off and exiting the sector. 
Equipped aircraft were displayed in green while 
unequipped aircraft were displayed in yellow (see 
Figure 3). For aircraft in the corridors, data blocks 
regardless of equipage were collapsible at any time. 
By default, equipped aircraft in the corridors were 
displayed with collapsed data blocks. The data blocks 
of unequipped aircraft in the corridors popped up 
when in hand off status. The colors used for corridors 



traffic were muted variants of the green and yellow 
used to denote the equipage of non-corridors traffic. 
Additional information was also included in corridor 
traffic data blocks that indicated time to entry or exit 
of corridors, and the assigned corridor for entering 
traffic. 

Additional TBX adjustments for the corridors 
study 

As the discussion above indicates, the operations 
were designed such that equipped aircraft within 
corridors could largely be ignored if there was no 
crossing traffic, while unequipped aircraft still had to 
be communicated with. These differences had to be 
captured in the TBX computations. We used simple 
adjustment equations for both, but the equipped 
aircraft in the corridors adjustment was implemented 
as a primary multiplicative effect, whereas the 
adjustment for unequipped in corridors was 
implemented as a secondary additive adjustment 

Equipped Aircraft in Corridors: 

VX EinC {s,t) = ( 9 ) 

where 

P x Einc is a primary complexity adjustment 
for the equipped aircraft in the corridors of 
sector s at time t 

ac Einc is the number of equipped aircraft 
predicted to be inside the corridors 

Unequipped Aircraft in Corridors: 

sx mnc (s,t) = l- acu ^ t) (10) 
where 

V x uinc is a secondary complexity adjustment 
for the unequipped aircraft in the corridors 

ac uinc is the number of unequipped aircraft 
predicted to be inside the corridors 

Please note that using the MAP value in the 
denominator can cause negative values if more 


aircraft enter the corridors than the MAP value. 
Therefore, the adjustment is not in line with the 
earlier requirement to stay within 0 and 2. However, 
the study was designed such that the con i dors traffic 
would never reach the MAP value, thereby keeping 
the adjustments to be positive. The effect of the 
corridors was likely overemphasized in any case and 
a more appropriate denominator than MAP might 
have been the actual aircraft count ac (s,t). 

TBX formulation for corridors study 

Equation (11) shows the TBX fonnula used 
during the corridors study in its entirety. 

The MAP value was set to 22 aircraft, and the 
equipage ratio to 50%. Weather was not used in this 
study; therefore the weather adjustment equaled 1 
and had no impact and so was not included in 
equation (11). In this study all weights in the 
secondary complexity adjustments were set to be 1 . 

Results 

The main results of the Corridors study will be 
presented in a future publication. We use only few 
data from the study here to show where TBX tracked 
well and where it needed to be improved. 

Metrics 

As metrics of interest for this discussion we use 
the controller workload, the aircraft count and the 
TBX value. For this discussion we use the controller 
workload that was measured on the Radar position. 
The measurement was based upon the ATWIT 
technique [12], Controllers were prompted every 3 
minutes to rate their workload on a scale of 1 to 6, 
given the guidelines indicated in Figure 4. Their 
rating was then recorded by the MACS data 
collection system. In the guidelines, we define the “in 
the Groove” rating as 3 and 4 and consider this to be 
the desirable level of workload. Ratings of 1 and 2 
are too low and reflect inefficiencies in controller 
resource utilization. Ratings of 5 and 6 are too high 
as the controller may not be able to use their best 
judgment. 


tbx{s, t) = ac(s, t) * px sv (s, t) * V x Ei nC {s, 0 + 


UC r 


1 0 ) * 


^ sx trs (s,t)+sx PrL0S (s,t)+sx C0n f(s,t)+sx UTleq (s,t)+sx uln cls,t ) 


- 1 ) 


( 11 ) 



1 - very low workload - very link- traffic - hardly anythin); to do - time to talk 

2 - low workload - light traffic - time to give best routes - time to talk 


„ r*~3 - somewhat low workload - in the groove - firm grasp of the flick - proactively looking for conflicts - still 
1 pros ide services 


i 


• 4 - somewhat high workload mostly in the groov e - still have the flick - proactive most of the time hut 
focusing more on the separation management over providing services or other tasks with less priority 


ITS- high workload having trouble keeping the flick working reaclivcly instead of proactively - relying 
heavily on automation tools 

| • 6- very high workload - on the verge of losing the flick - reactive and scramble mode - falling behind in routine 

tasks - cannot take on any additional tasks 


• Remember that your rating is intended to reflect your workload at the moment you are prompted, not your general 
appraisal of workload for the whole scenario 


• Workload is a very important measure for data analysis please try to respond to every prompt 


Figure 4: Guidelines given to the controllers for rating their workload on a scale of 1 to 6 


We define aircraft count as the number of 
aircraft that are within the lateral and vertical 
boundaries of the sector of interest. This data was 
collected during the runs by the MACS built-in data 
collection system. Given that the goal is to keep the 
controller workload at 4 or less, the maximum 
allowable aircraft count under nominal conditions 
should correspond to a workload rating between 4 
and 5. The MAP value was established at 22 aircraft 
for the nominal conditions that were defined with no 
corridors and a 50% equipage ratio. 

The TBX value was computed in real-time as 
indicated in equation (11). In line with the prior 
discussion and the definition of TBX, a TBX value of 
22 would reflect the maximum permissible workload 
under all conditions. 

We will now look at the results of 2 sectors with 
very different characteristics (see Figure 2). Sector 
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49, which is nearly square, has only one corridor in 
the corridors condition and feeds traffic into the 
corridors. Sector 79 accommodates two corridors and 
has a very different shape. We will first discuss the 
no corridors condition (NC) and then the condition of 
equipped aircraft in corridors (EinC). 


No Corridors (NC) condition 

The No corridors condition was considered as 
our nominal condition. Therefore, in this condition 
aircraft count was considered a good predictor of 
complexity and we expected the TBX value to be 
very close to aircraft count. Figure 5 shows workload 
rating, aircraft count and TBX rating for the NC 
condition in sector 49. As expected, both TBX and 
aircraft count were fairly good predictors for 
controller workload. Figure 6 shows similar results 
for sector 79. 


Both plots are laid out such that the MAP value 



Figure 5: TBX, aircraft count and workload for 
sector 49 in NC condition 


Figure 6: TBX, aircraft count and workload for 
sector 79 in NC condition 




of 22 crosses the workload axis between 4 and 5. 
This means that as long as TBX is kept below MAP it 
is expected that the workload will be below 5. TBX, 
aircraft count and workload align well in both 
sectors. Both, TBX and aircraft count are usable 
predictors of controller workload with the TBX 
predictions being slightly higher and better than 
aircraft count. In the case of sector 49, TBX 
computed a value exceeding MAP about 40 minutes 
into the run that the aircraft count did not show. 
Otherwise, since the NC condition basically reflected 
our nominal case, TBX and aircraft count are very 
similar. 

It should also be noted that the traffic managers 
and supervisors used TBX predictions in these runs 
to actively manage controller workload. The 
scenarios were designed to reach aircraft counts of up 
to 30 aircraft and the operators actively rerouted 
aircraft and changed their altitude to keep the 
workload manageable. Therefore, the result indicated 
a high but not excessive workload throughout the 
simulation run. This is not a coincidence but rather a 
consequence of actively managing traffic and 
resources based upon the TBX predictions. 

Equipped in Corridors (EinC) 

We use the “Equipped in Corridors” (EinC) 
condition as the second condition for our discussion 
because it is the condition that had the biggest 
differences from our nominal (NC) case. The 
complexity hypothesis for the EinC condition was 
that equipped aircraft in corridors could practically be 
ignored by the controllers due to an assumption that 
they required little monitoring effort and did not 
require clearances to issue for the controllers. This is 
reflected in our adjustment made for equipped 
aircraft in corridors. Equation (9) means that 
equipped aircraft in corridors can essentially be 

Equipped In Corrdiors - Sector 49 

30 T r 6 
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Figure 7: TBX, aircraft count, revised TBX and 
workload for sector 49 in EinC condition 


removed from the aircraft count to compute TBX 
when the overall aircraft count is around MAP. 

The plots in Figures 7 and 8 show the aircraft 
count, TBX and workload results for the EinC 
condition. The aircraft count for both sectors reaches 
25 and exceeds the MAP value for sustained periods 
of time. The workload however, hardly ever exceeds 
4 is therefore well within the manageable range. 
Using only aircraft count, several aircraft would have 
been therefore unnecessarily removed from the 
sectors. While the TBX value for sector 49 appeared 
to be only slightly under-predicting the workload, it 
under-predicted the workload substantially for sector 
79. The difference is due to the much larger amount 
of aircraft on corridors in sector 79 and the fact that a 
D-Side was added to sector 49 usually at about 35 
minutes which immediately caused a workload 
reduction for the R-Side. 

Elowever, the data for sector 79 (Figure 8), show 
that the TBX value was clearly too low for this 
condition and did not accurately reflect the 
controllers’ workload for the EinC condition. In 
interviews with controllers and during observations it 
was noted that the equipped aircraft in Corridors 
could only be ignored if there was no traffic trying to 
cross the corridors (usually on a climb trajectory) and 
if the corridors traffic did not have to exit the 
corridors within the sectors. Both of these conditions 
were only true for approximately half the aircraft on 
the corridors. Therefore, after the study we corrected 
our adjustment for Equipped in Corridors as follows: 

pxEincis, t) = 1 - 0.5 * aCEi ^ t] (10) 
where 

P x Einc i s a primary complexity adjustment 
for the equipped aircraft in the corridors of 



Figure 8: TBX, aircraft count, revised TBX and 
workload for sector 79 in EinC condition 



sector s at time t 

ac Einc is the number of equipped aircraft 
predicted to be inside the corridors 

Using this adjustment we recomputed the TBX 
value and plotted it for both sectors as “TBX 
(revised)”. The revised TBX matches the controller 
workload much better. To address the remaining 
mismatches we could adapt the secondary 
adjustments and weights of transitioning aircraft and 
conflicts to the respective sectors. We believe by 
doing so, we would get an extremely good TBX 
prediction for all sectors and condition. However, it 
will never be perfect and it does not have to be, as 
long as it can predict potentially difficult situations in 
time for the operators to make informed decisions. 

Conclusion 

We have developed a new complexity metric 
aggregate called TBX. TBX is a modified aircraft 
count for trajectory-based operations. TBX uses a 
simple framework to adjust the aircraft count 
according to variations of tractable and predictable 
primary and secondary complexity factors. We have 
used TBX during a number of human-in-the-loop 
simulations over the past few years, and TMCs and 
area supervisors were able to successfully manage 
controller resources and workload with TBX. TBX 
computations can easily be iterated and adjusted to 
the specific properties of sectors and operations and 
can improve the efficiency of traffic and resource 
management decisions. 
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